Reject oversized JSON submit batches before verify - #424

Description

Clean-room rewrite of the intent of aptos-labs/aptos-core@fe434ebe (early JSON batch size check). No aptos-labs code was cherry-picked or copied. This change was written from scratch against the m1 handler.

Problem: POST /transactions/batch accepted a JSON array, then ran VerifyInput (and later signed-txn conversion) on every item before enforcing max_submit_transaction_batch_size. An oversized JSON batch could burn CPU on payload/signature checks that would be discarded.

Invariant: If a JSON submit-batch array is already longer than max_submit_transaction_batch_size, the handler returns 400 / invalid_input before verify() and before get_signed_transactions_batch. BCS cannot be counted until it is decoded, so the existing post-parse cap stays as the BCS path (and as a backstop).

What changed (crate api only):

• reject_json_batch_if_over_configured_limit runs first on SubmitTransactionsBatchPost::Json.
• The post-decode size check is unchanged for BCS.

How Has This Been Tested?

Ran locally:

cargo test -p aptos-api --lib test_submit_batch

3 passed; 0 failed

• test_submit_batch_rejects_oversized_json_before_verify — two expired-but-parseable JSON items with limit 1 fail on the count cap, not expiration (proves verify is skipped).
• test_submit_batch_json_at_limit_still_verifies_items — two expired items with limit 2 still fail verify (cap is >, not >=).
• test_submit_batch_rejects_oversized_bcs_after_decode — two signed txns as BCS with limit 1 still 400 after decode.

Key Areas to Review

• Ordering in submit_transactions_batch: JSON length gate, then verify(), then decode, then BCS backstop.
• Error text matches the existing late-check message so clients that parse it keep working.

Aikido / security notes (new code only)

• DoS: this is a request-count gate, not a body-size gate. It stops per-item verify work after JSON deserialize. HTTP Content-Length is still handled by existing PostSizeLimit.
• Comparison: submitted > limit on usize; no wrapping math, no unwrap on user input.
• BCS: count is unknown until decode; we still deserialize then refuse before mempool submit. That decode cost is unavoidable for BCS.
• Errors: same InvalidInput + message shape as the existing late check. Early JSON path uses bad_request_with_code_no_info because ledger headers are not fetched yet.
• No unsafe / no new parsers.

Type of Change

• New feature
• Bug fix
• Breaking change
• Performance improvement
• Refactoring
• Dependency update
• Documentation update
• Tests

Which Components or Systems Does This Change Impact?

• Validator Node
• Full Node (API, Indexer, etc.)
• Move/Aptos Virtual Machine
• Aptos Framework
• Aptos CLI/SDK
• Developer Infrastructure
• Move Compiler
• Other (specify)

Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I tested both happy and unhappy path of the functionality

  

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}